In database systems, a “transaction” refers to an atomic set of operations performed against a database, which may access, create, modify or delete database data or metadata. A “commit” occurs when the transaction has completed its processing and any changes to the database by the transaction are ready to be permanently implemented in the database system.
Transaction log records can be maintained in a database system to allow data recovery in the event of an error, that may include hardware failure, network failure, process failure, database instance failure, data access conflicts, user errors, and statement failures in database access programs.
Various types of transaction log records can be maintained in a database system for data recovery. One type of log record that may be maintained is the “undo” record. Undo records contain information about changes that were introduced into the database system. For example, if a row in a table were modified, the changes will be stored in the undo record identifying the block of the database system that includes the modified table row.
Memory or disk space needs to be allocated for storage of undo records. Database managers may set the undo tablespace size by predicting how many undo records may be generated. Often there is not enough statistical information available for database administrators to use in order to arrive at an accurate prediction of undo records generation. Incorrect undo tablespace size may cause errors in the system, as not enough undo records may be available. Alternatively, allocating too much memory or disk space for storing undo records is inefficient.
Moreover, database administrators need to predict how long undo records should be maintained, a parameter known as the “undo retention.” Users may require older versions of the data for various reasons. In order to prevent these users from obtaining error messages, undo records should be maintained in the system to allow the data to be retained to their previous values. However, undo tablespace is limited, and new transactions require undo tablespace. A user may therefore monitor the system activity and adjust the undo retention based on the amount of undo information generated by new transactions.
Undo records that are generated by active transactions may be known as active undo records. Undo records generated by relatively recent transactions, which committed more recently than the undo retention, may be referred to as “unexpired undo records.” Undo records that were generated by relatively older transactions, which committed more distantly than the undo retention, may be referred to as “expired undo records.”
When the allocated undo tablespace is too small or the system activity exceeds predicted levels, the system may encounter a condition known as “space pressure.” Under space pressure, the undo tablespace may be severely limited. Because a transaction cannot succeed without storing undo records, transactions may be in danger of failing for lack of undo tablespace. Under such conditions, many database systems choose to eliminate existing undo records of non-active transactions and thus risk failing a query, rather than failing the transaction. Such database systems usually do not eliminate active undo records, and usually may choose to eliminate any expired undo records first. However, if no expired undo records can be found, these systems may choose to eliminate unexpired undo records. Such systems may eliminate unexpired undo records indiscriminately, eliminating newer undo records while older undo records remain in the system. This indiscriminate method of eliminating undo records may result in an unacceptable number of failed queries and other operations.
What is needed, therefore, is a solution that overcomes these and other shortcomings of the prior art.